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Abstract 

The need for both robust and unambiguous 
electronic designs is a direct require- 
ment of the astonishing growth in design 
and manufacturing capability during re- 
cent years [1,2], In order to manage the 
plethora of designs, and have the design 
data both interchangeable and inter- 
operable, the Very High Speed Integrated 
Circuits (VHSIC) program is developing 
two major standards for the electronic 
design community. The VHSIC Hardware 
Description Language (VHDL) is designed 
to be the lingua franca for transmission 
of design data between designers and 
their environments. The Engineering 
Information System (EIS) is designed to 
ease the integration of data between di- 
verse design automation systems. This 
paper describes the rational for the 
necessity of these two standards and how 
they provide a synergistic expressive 
capability across the macrocosm of de- 
sign environments. 

The Rational 

The VHSIC Program has propelled forward 
the design density of electronic systems 
to a point where current computer aided 
design tools, design representations, 
and the corresponding data management 
systems begin to limit the designers' 
ability to design throughout the con- 
tinuum of system levels to physical 
levels. In order to provide mechanisms 
for designers in the next decade, the 
VHSIC program has several design automa- 
tion efforts under-way in its Technical 
Insertion and System Level Design tool 
subprograms. The dual focus of these 
subprograms is use of VHDL as the nota- 
tion for design/description and the EIS 
for integration of design data. Initia- 
tion of the the VHDL proqram was moti- 
vated by the diversity of design nota- 
tions that failed to encompass the broad 
range of descriptive capability required 


for advanced system documentation, and 
by the need of the DoD to provide a 
standard descriptive notation for sys- 
tems that have life-spans upward of fif- 
teen years. The VHSIC Hardware Descri- 
ption Language provides an economical 
method to decrease the system design 
time and cost of government re-procured 
ICs. Design costs for ICs are now in 
the range of $2 to $5 million and devel- 
opment costs must be reduced to meet fu- 
ture needs. Maintaining and upgrading 
electronic systems in inventory demands 
specific, current, and rigorous descrip- 
tions. As English can be vague, and 
fraught with idiomatic contextual refer- 
ences, the automation of design and de- 
sign verification demands a technology 
independent, rigorous notation as is 
VHDL. 

The EIS is envisioned to provide effic- 
iency for the design process and to ease 
the insertion of VHSIC technology into 
electronic defense systems. To this end 
the development of an integrated design, 
documentation, and life-cycle mainten- 
ance system for complex electronic sys- 
tems must support initial specification 
design data capture to fabrication and 
testing data in one continuum. An EIS 
system is not, and would not, be avail- 
able from the commercial sector due to 
the high cost of development for a 
"turn-key” system being beyond most bus- 
inesses. Therefore design automation 
tool users are forced to integrate an 
assortment of design tools from other 
vendors and those that are developed 
internally. The unique, proprietary, 
and internal design representations of 
each vendors' design automation tool 
complicates the integration task dras- 
tically. Integration has been a sever 
problem (3,4) while integration is known 
to be beneficial [5,6]; thus the EIS has 
as its main goal the reduction of the 
present difficulties involved with in- 
tgration of different vendors' design 
tools by developing a set of inter-oper- 
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ability standards and then demonstrating 
them. The VHDL in total is to be used 
in the EIS system as the design documen- 
tation formalism required of complex 
electronic systems. 

VHDL -- The Lingua Franca 

A standard hardware description language 
benefits all industries that depend on 
electronics. By its use the problem of 
a second source can be greatly reduced. 
But how is this accomplished? What 
makes the VHDL such a beneficial nota- 
tion for electronic design? From the 
inception of a standard hardware desc- 
ription language [7] the focus of the 
language was to allow a hierarchical 
continuum of design notation from the 
system to gate level. A discussion of 
the language hierarchy must begin at its 
basic building block, the design entity ; 
and then progress through its other fea- 
tures to show the capability of the lan- 
guage for electronic design and the the 
transfer of that design from designer to 
designe r . 

The design entity is the principal 
hardware abstraction in VHDL. A design 
entity provides the separation of 
interface and function to allow a 
hierarchical design decomposition. The 
crux of the design entity is the 
interface which allows the entity to be 
combined with other components. The 
interface is the abstraction's "pin-out" 
that describes the data paths and other 
factors that need to be known by 
component users. The secondary part to 
a design entity is its body which 
describes the organization and/or 
operation of a component. As an 
abstraction, the entity interface may 
possess multiple bodies, each 
representing a different implementation 
or emphasizing a different view of 
design. A design entity models 
electronics of any intricacy. Examples 
would be a logic gate, a flip-flop, a 
control unit, or a computer system. In 
fact, the range is only limited by the 
imagination of the designer as design 
entities can be used to describe any 
physical object having a bounded 
identity. 

The design entity interface contains in- 
formation that is common to the bodies 
that use the entity interface. This in- 
formation includes data that is visible 
and is not visible externally. Of the 
visible data there are two types p orts 
and generics . The non-visible informa- 
tion may define types, constants, and 
attributes that are used by the alter- 
nate bodies of the entity. Inclusive of 


the object information, the interface 
can contain assertions that specify 
operating properties and operational 
circumstances of the entity. Operating 
properties specify desired timing or fu- 
nctional relationships demonstrated by 
the entity. Operating circumstances 
specify external conditions that must be 
stated in order for the entity to cor- 
rectly model its component. 

To define communication channels among 
design entities and the outside world, 
the port data describes the mode and 
type of that information. To pass data 
that is not part of an entity's port 
interface, but is important to the oper- 
ating circumstances, the design entity 
interface may have generics . For examp- 
le, a generic value would be passed to 
the entity to specify a particular tech- 
nology that the design entity is repre- 
senting. Generics may represent instan- 
tiations of preconditions for execution. 

Given the interface of a design entity, 
the designer provides a body that will 
describe the function of the entity. In 
VHDL there are two major divisions of 
entity bodies; the architectural body 
that expresses the data transformations 
that occur within the entity and the 
configuration body that controls the 
choice of design entities that are used 
to model sub - components and the distri- 
bution of signal definitions. 

In an architectural body the description 
styles that designers use roughly fall 
into three categories: structural, data- 
-flow, and behavioral. As is implied, 
structural description is approximately 
equivalent to the schematic connection 
of electronic components. The data-flow 
description method consists of register 
transfer level data transforms. The be- 
havioral method of description allows 
the designer to specify transforms in 
wholly algorithmic terms. Any given 
architectural body may use these three 
general forms of description inter- 
changeably. 

With the capability of developing a li- 
brary of similar component designs, it 
is desirable to make use of existing en- 
tities even if names or ports are not 
exactly what are required, but a subset 
interface will suffice. Additionally, a 
design series can have multiple config- 
urations, each using slightly different 
design entities to implement the given 
component's behavior. The configuration 
body, which contains the configuraton 
specification, provides the ability to 
respecify the default association rules 
so that an architectural body's compo- 


120 



nents may be bound to corresponding but 
not identical design entities. The 
architectural bodies must preceed the 
configuration bodies which use them. In 
this way a configuration body can add or 
modify the enity configuration post-de- 
sign without altering its basic archi- 
tecture . 


With the basic structural elements of 
the VHDL identified, the data of such a 
block structured language must follow in 
rigor, and scope. The VHDL is a strong- 
ly typed language based on the syntax 
and semantics of Ada. With this being 
known, the VHDL supports descriptions of 
objects from the typical bit values of 
'O' and '1' to higher levels of abstrac- 
tion such as "integer," "message pack- 
et," and "instruction." With the range 
of data that can be described, VHDL 
avoids the pit-fall of predefining data 
types available to the designer. This 
gives the designer the ability to com- 
pletely describe new data types as they 
are needed. The set of types available 
to the designer include predefined types 
such as BIT, BOOLEAN, REAL, INTEGER, 
CHARACTER, and TIME. Additionally all 
scalar and composite types are allowed. 
These types would include enumeration 
types, physical types (allowing expres- 
sion of measurement defined in a base 
unit), records, and multidimensional 
arrays. VHDL has the ability to create 
functions and procedures and place these 
in packages to enable the designer to 
encapsulate algorithmic behavior. 


The two most salient features of VHDL 
for future application to artificial 
intelligence are the ability to create 
and attach attributes to objects and 
have liturgical assertions that have 
global scope for a design entity. As 
new technologies emerge for design and 
construction of electronic circuits, 
VHDL provides an attribute mechanism 
that allows designers to associate extra 
information with descriptions of 
components or parts of components. As 
attributes can be referenced in VHDL 
this allows entities and data-objects to 
have LlSP-like atom properties. This 
capability is useful in intelligent 
silicon compilation [8,9,10]. In order 
to produce designs that are both eff- 
icient, and more importantly correct, 
the VHDL has the assertion ability req- 
uired in many verification systems [11]. 
Assertion statements check static or 
dynamic conditions that are either 
checked prior to simulation or during 
simulation as signal values change. 
Assertions may occur at any point in a 
VHDL description and are user control- 
lable in order to report the condition 
of the entity. 


El S -- The Pax Romana 


In 1984 the disparity due to the diver- 
sity of design formats and languages 
prompted outcries from industry where 
the future was seen as, 

"A nightmare of incompatible 
formats and a babel of diff- 
erent languages ."[ 12 ] 

The rhetorical question would be, "Has 
it gotten any better since 1984?" From 
the surveys of design systems available 
in the trade press, the answer is no; 
although efforts by IC designers and 
fabricators have produced draft inter- 
change formats (e.g. EDI F ) . In order to 
couple the large amount of distributed 
database designs many individual trans- 
lators have been written. Such one-on- 
one translation does not provide the in- 
tegration necessary for automated design 
and fabrication. Without data integra- 
tion, no amount of automation will over- 
come the data interchange problem. 

A series of workshops were held to form 
a base-line for what would constitute 
the requirements for an EIS. More than 
150 people representing near as many 
organizations attended the workshops . 
The result was the creation of the DoD 
Requirements for Engineering Informat- 
ion Systems [13]. Five key areas for an 
EIS were identified by the participants. 
An EIS must support: 

• the reuse of design information 
from all forms of input, 

• an information repository and 
data caputre designed for a multi- 
base, heterogeneous environment , 

an interface to its information 
model such that it economically 
supports integration of existing CAE 
software , 

• a system that is not monolithic 
in use so that installations may 
tailor the system for current and 
future needs, and 

• the efficiency to support the 
above functionality in its opera- 
tion . 

The architecture of the EIS is rooted in 
its information model; which when used, 
provides a Pax Romana (enforced peace) 
on the conflict of data representation 
and data usage. This Information Model 
is the focus of the EIS effort that will 
allow the identified key area to be 
achieved. The requirements are that, 

"The EIS must provide a model 
of the classes of engineering 
information that are needed to 
accurately describe the sem- 
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antics of the information in 
the engineering environment in 
which the EIS operates. The 
El S Engineering Information 
Model (EIM) need not be used to 
actually represent engineering 
data; this is the purpose of 
the common exchange format. 
Rather# it must provide a def- 
inition of all information 
classes and modeling rules 
needed as the basis for formu- 
lating a conceptual framework 
for information exhange . " [ 1 4 ] 

It is this semantic description of engi- 
neering information that provides the 
knowledge -based technology that disting- 
uishes the EIS effort from other data- 
dictionary based, multi-view databases. 
It is the goal of the EIM to have the 
specification of semantics in a precise 
and understandable form. The informa- 
tion classes and prescribed modeling 
rules will ensure that the allowable 
combinations of the data can be modeled 
in exactly one way; the are no redundant 
EIM models of the same data within the 
system . 

A goal of the EIS is to develop an 
accepted Common Exchange Format (CEF) in 
order to promote the exchange of data 
between design systems, repositories and 
organizations. From the experience 
gained in the development of the VHDL , 
the important factor in data exchange is 
the information model. Once the model 
is developed, the development of the ex- 
change format is one of representation 
notation design. The Object-Oriented 
Data Language will be used in the EIS 
for defining the syntax for manipulating 
objects maintained within an EIS. The 
PROBE Data Model, an object-oriented ex- 
tension of DAPLEI'C, developed by Computer 
Corporation of America. DAPLEX is a 
semantic data model and query language 
that will provide the necessary features 
for an object-oriented information mod- 
el; such as 

• the concept of an entity or ob- 
ject that has existence independent 
of its properties or relationships, 

• support for relationships between 
objects and for set-valued proper- 
ties, and 

types and gene ral i za t i on hier- 
archies with inheritance. 

For access to repositories through the 
EIS the Object-Oriented Data Language 
will be used as the CEF between EIS 
installations. In addition, data ex- 
change adapters will be used to trans- 
port design data via VHDL and EDIF. Al- 


ternate exchange formats, such as a sub- 
stantial portion of SQL will be used for 
non-ElS installations as the program de- 
velops thus allowing an interface to 
foreign information models. 

The Object Manager of the EIS is the 
responsible "agent" for managing objects 
and functions. It registers new ob- 
jects, deletes objects that are unneed- 
ed, locates and retrieves objects, and 
provides access to objects. The Object 
Manager provides services for resolving 
object references in bindings with 
application to 1) persistent and 
temporary objects (data and events), 2) 
stored and derived objects (database and 
computed), and 3) passive and active ob- 
jects (data and processes). Implementa- 
tion of the Object Manager is based on 
the design and facilities of the ENCORE 
system by Brown University. 

With the EIS Information Model key-stone 
set within the EIS, the representation 
of data is best controlled through 
rule - processing and control - point 
activation of data management functions. 
The short-term requirements for 
rule-based processing of EIM data are 
that , 

’’Rule processing must be sup- 
ported by programs that imple- 
ment all required management 
and control and other rule- 
based capabilities. There must 
be an interface specification 
for every situation in which 
rule processing is necessary 
that allows proqrams to invoke 
appropriate rule processing 
programs and pass parameters to 
them. Rule processing may be 
implemented via object programs 
in the short term...." "The 
EIS must be able to invoke the 
rule processing services in a 
heterogeneous, distributed en- 
vironment. The services must 
fulfill tool availability req- 
uirements . . . " ( 15 ] 

In the extended short-term requirements, 
the general rule-based system which 
allowed object programs to have static 
knowledge-bases is modified so that, 

"All rule-based capabilities 
required by the EIS must be 
provided by a rule processor, 
which can be invoked through 
programs that use the speci- 
fied" [note: CAIS] "standard 
interfaces. The rule processor 
must support the execution of 
rules specified by a rule spec- 
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ification language. The EIS 
must support facilities for 
adding, deleting, and modifying 
rules. The rule specification 
language must support the con- 
cept of system supplied variab- 
les..." "and must support eval- 
uation of expressions, condi- 
tion testing and the triggering 
of actions. The rule speci- 
fication language must allow 
for the specification of ac- 
tions, including sending mess- 
ages, changing global and ob- 
ject-related management and 
control information, and invok- 
ing programs. The rule speci- 
fication language must support 
the concept of variables and 
parameters. The rule specifi- 
cation language must permit use 
of any type of object as a var- 
iable or parameter and must al- 
low for the specification of 
parameterized queries contain- 
ing update operations against 
ElS-managed data. The EIS, in 
combination with the rule pro- 
cessor, must be able to support 
the concept of parameterized 
messages and programs, and must 
be able to supply the parameter 
instantiations automatically." 

[ 16 ] 

Thus the EIS Information Model is based 
on processing information using a multi - 
rule knowledge base in a multi -base en- 
vironment. From this foundation the ex- 
change of information among diverse en- 
vironments is no longer a matter of for- 
mat, but is one of semantics. 

Summary 

This paper has covered the descriptive 
capability and control mechanisms of 
the VHDL and the Information Model 
structure of the EIS. It is the purpose 
of both of these standards efforts to 
promote the interchange of electronic 
design data through the semantic content 
of the data rather than in its physical- 
/logical format. It is the intent that 
both of these "tools," a language and an 
envi ronment, will be platforms from which 
knowledge based electronics design may 
continue forward. Internal to the VHDL 
there exist the necessary control struc- 
tures and proof mechanisms for the lan- 
guage to be the input to a formal proof 
of correctness system as done by Dr. 
Luckham at Stanford University. As has 
been described above, the EIS Informa- 
tion Model is to be based on known know- 
ledge-base requirements and techniques. 
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